1. Field of the Invention
This invention relates generally to defining a data monitoring point in a system for integrated fault-isolation and fault-tolerance analysis of an in-vehicle embedded electrical and electronic system (EES) and, more particularly, to a system and method for defining a data monitoring point for integrated fault-isolation and fault-tolerance analysis of an in-vehicle embedded EES that includes defining the EES as a network model, calculating a betweenness centrality metric for each potential monitoring point in the model, ranking the betweenness centrality metrics and selecting the potential monitoring point with the highest betweenness centrality metric as the actual monitoring point if it satisfies a predetermined coverage defined by a degree of neighbor factor.
2. Discussion of the Related Art
Modern vehicles are complex electrical and mechanical systems that employ many components, devices, modules, sub-systems, etc., such as embedded electrical and electronic systems (EES), that pass electrical information between and among each other using sophisticated algorithms and data buses. Vehicle EESs are becoming much more complex as they have evolved in response to a continuously increasing demand for incorporating electronic and electrical control units (ECUs) into vehicles. For example, a modern high end vehicle may include seventy or more ECUs to provide control and command operations for the EESs on the vehicle. These control units allow for advanced safety, convenience and comfort features, as well as meeting new emissions and fuel-economy standards. However, the fast growing number of ECUs and their peripherals on a vehicle has led to complex interactions that sometimes cause unexpected behaviors, such as emerging or cascading failures.
As with anything, EESs and ECUs are susceptible to errors, failures and faults that could affect the operation of the vehicle. The algorithms operating in the ECUs generate information and calculations from data stored in memory. Further, signals may be transferred between ECUs along wiring to cause certain operations to be performed, such as actuating an actuator. All of this information could be corrupted in some fashion, such as a result of loose wiring, memory failure, calculation inaccuracies, etc. Thus, the transfer of data or messages between different elements in the system, whether it is along a physical wire or within software, can be used to determine faults. Furthermore, the current techniques employed in integrated vehicle health management (IVHM) and active safety systems are still lacking in standardization and metrics for addressing the needs for improving and quantifying maintainability and complexity in the EESs.
When such errors and faults occur, often the affected device or component will issue a fault code, such as diagnostic trouble code (DTC), that is received by one or more system controllers identifying the fault, or some ancillary fault with an integrated component. In order to be able to detect and analyze DTCs and other faults, it is necessary to collect data that is required to identify and isolate the faults, and collect the data at the proper location. Once the data is collected, diagnostic algorithms are employed to analyze and process the data and provide it in a format that can be analyzed. Once the data has been processed, then the root cause of the fault can be identified. For example, DTCs can be analyzed by service technicians and engineers to identify problems and/or make system corrections and upgrades. Diagnostic modeling includes determining the root cause of a problem that has already occurred. Known fault modeling methods for diagnosing component and sub-system faults may use Bayesian networks, dynamic Bayesian networks, hidden Markov models, fuzzy logic, belief networks, Petri net, etc.
Sometimes sensors are provided to collect the data at the desirable locations in the EES and/or ECUs to provide the information necessary to be used by the diagnostic algorithm to identify the cause of a problem. Further, especially in sophisticated vehicles, the data collection often includes monitoring messages and other information transmitted between the ECUs. The data and information being collected may be messages transmitted between the ECUs or data available in a particular memory in an ECU. Although it may be desirable on some level to provide monitoring points at every possible location to collect sufficient data to clearly identify a problem, such a scheme is impractical and ultimately too costly. Therefore, it is necessary to identify the best monitoring points that will provide the most usable information. Known techniques for identifying the best monitoring points in and between an EES and/or ECUs has heretofore been limited.